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Abstract 

From the type of a polymorphic function we can de¬ 
rive a theorem that it satisfies. Every function of the 
same type satisfies the same theorem. This provides 
a free source of useful theorems, courtesy of Reynolds’ 
abstraction theorem for the polymorphic lambda calcu¬ 
lus. 


1 Introduction 

Write down the definition of a polymorphic function on 
a piece of paper. Tell me its type, but be careful not 
to let me see the function’s definition. I will tell you a 
theorem that the function satisfies. 

The purpose of this paper is to explain the trick. But 
first, let’s look at an example. 

Say that r is a function of type 

r : VX. X* -A X*. 

Elere X is a type variable, and X* is the type “list of X” . 
From this, as we shall see, it is possible to conclude that 
r satisfies the following theorem: for all types A and A' 
and every total function a : A —> A' we have 

Elere o is function composition, and a* : A* ^ A'* is 
the function “map a” that applies a elementwise to a 
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list of A yielding a list of A' , and pa : A* —> A* is the 
instance of r at type A. 

The intuitive explanation of this result is that r must 
work on lists of X for any type X. Since r is provided 
with no operations on values of type X, all it can do is 
rearrange such lists, independent of the values contained 
in them. Thus applying a to each element of a list and 
then rearranging yields the same result as rearranging 
and then applying a to each element. 

For instance, r may be the function reverse : 
VX. X* -A X* that reverses a list, and a may be the 
function code : Char -A Int that converts a character to 
its ASCII code. Then we have 

code* {reversechar [‘a’, ‘b’, ‘c’]) 

= [99,98,97] 

— reverseint {code* [‘a’, ‘b’, ‘c’]) 

which satisfies the theorem. Or r may be the function 
tail : VX. X* —1- X* that returns all but the first element 
of a list, and a may be the function me : Int -A Int that 
adds one to an integer. Then we have 

me* {tail Int [1,2, 3]) 

= [3,4] 

= tail Int {me* [1,2, 3]) 

which also satisfies the theorem. 

On the other hand, say r is the function odds : Int* -A 
Int* that removes all odd elements from a list of inte¬ 
gers, and say a is me as before. Now we have 

me* ( oddsi n t [1,2, 3}) 

= [2,4] 

± [4] 

= odds Int {inc* [1,2,3]) 

and the theorem is not satisfied. But this is not a coun¬ 
terexample, because odds has the wrong type: it is too 
specific, Int* -A Int* rather than VX. X* -A X*. 

This theorem about functions of type VX. X* — y X* is 
pleasant but not earth-shaking. What is more exciting 
is that a similar theorem can be derived for every type. 





The result that allows theorems to be derived from 
types will be referred to as the parametricity result, be¬ 
cause it depends in an essential way on parametric poly¬ 
morphism (types of the form MX. T). Parametricity is 
just a reformulation of Reynolds’ abstraction theorem: 
terms evaluated in related environments yield related 
values [Rey83]. The key idea is that types may be read 
as relations. This result will be explained in Section 2 
and stated more formally in Section 6. 

Some further applications of parametricity are shown 
in Figure 1, which shows several types and the corre¬ 
sponding theorems. Each name was chosen, of course, 
to suggest a particular function of the named type, but 
the associated theorems hold for any function that has 
the same type (so long as it can be defined as a term in 
the pure polymorphic lambda calculus). For example, 
the theorem given for head also holds for last, and the 
theorem given for sort also holds for nub (see Section 3). 

The theorems are expressed using operations on func¬ 
tions that correspond to operations on types. Corre¬ 
sponding to the list type A* is the map operation a* 
that takes the function a : A —> A' into the func¬ 
tion a* : A* —> A' . Similarly, corresponding to the 
product type A x B is the operation a x b that takes 
the functions a : A —> A' and b : B —>■ B' into the 
function a x b : A x B —>■ A' x B'\ it is defined by 
(a x b) ( x , y) = (a x,b y). As we shall see, it will be 
necessary to generalise to the case where a, b, a* , and 
a x b are relations. 

Flow useful are the theorems so generated? Only time 
and experience will tell, but some initial results are en¬ 
couraging: 

• In general, the laws derived from types are of a 
form useful for algebraic manipulation. For exam¬ 
ple, many of the laws in Figure 1 allow one to “push 
map through a function” . 

• Three years ago, Barrett and I wrote a paper 
on the derivation of an algorithm for compiling 
pattern-matching in functional languages [BW86]. 
The derivation used nine general theorems about 
higher-order functions such as map and sort. Look¬ 
ing at the paper again now, it turns out that of 
the nine theorems, five follow immediately from the 
types. 

• Sheeran has developed a formal approach to the 
design of VLSI circuits that makes heavy use of 
mathematical laws. She has found that many of 
the laws she needs can be generated from types 
using the methods described here, and has already 
written a paper describing how to do so [She89]. 

Not surprisingly, using a more specific type system al¬ 
lows even more theorems to be derived from the type of 


a function; this has already been explored to a certain 
extent by Sheeran [She89]. So there is reason to believe 
that further research will further extend the applicabil¬ 
ity of this method. 

Many functional languages, including Standard ML 
[Mil84, Mil87], Miranda 1 [Tur85], and Haskell [HW88], 
are based on the Hindley/Milner type system [Hin69, 
Mil78, DM82]. This system is popular because types 
need not be given explicitly; instead, the principal (most 
general) type of a function can be inferred from its def¬ 
inition. However, for the purposes of this paper it is 
more convenient to use the Girard/Reynolds type sys¬ 
tem [Gir72, Gir86, Rey74, Rey83] (also known as the 
polymorphic lambda calculus, the second order lambda 
calculus, and System F). In the Girard/Reynolds sys¬ 
tem it is necessary to give the types of bound vari¬ 
ables explicitly. Further, if a function has a polymorphic 
type then type applications must be explicitly indicated. 
This is done via subscripting; for example, the instance 
of the function r : MX. X* —> X* at the type A is written 
r A : A* ^ A*. 

Every program in the Hindley/Milner system can 
automatically be translated into one in the Gi¬ 
rard/Reynolds system. All that is required is a straight¬ 
forward modification of the type inference algorithm to 
decorate programs with the appropriate type informa¬ 
tion. On the other hand, the inverse translation is not 
always possible, because the Girard/Reynolds system is 
more powerful than Hindley/Milner. 

Both the Hindley/Milner and the Girard/Reynolds 
system satisfy the strong normalisation property: every 
term has a normal form, and every reduction sequence 
leads to this normal form. As a corollary, it follows that 
the hxpoint operator, 

fix : MX. (X ->■ X) ->■ V 

cannot be defined as a term in these systems. For many 
purposes, we can get along fine without the hxpoint 
operator, because many useful functions (including all 
those shown in Figure 1) may be defined in the Gi¬ 
rard/Reynolds system without its use. Indeed, every 
recursive function that can be proved total in second- 
order Peano arithmetic can be written as a term in 
the Girard/Reynolds calculus [FL083, Gir72, GLT89]. 
This includes, for instance, Ackerman’s function (see 
[Rey85]), but it excludes interpreters for most languages 
(including the Girard/Reynolds calculus itself). 

If the power of unbounded recursion is truly required, 
then fix can be added as a primitive. However, adding 
hxpoints weakens the power of the parametricity the¬ 
orem. In particular, if hxpoints are allowed then the 
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theorems in Figure 1 hold in general only when the 
functions a and b are strict (that is, when a _L = _L 
and b _L = _L) . For this reason, the bulk of this pa¬ 
per assumes that hxpoints are not provided; but the 
necessary adjustment to allow hxpoints is described in 
Section 7. 

The fundamental idea of parametricity is not new. 
A restricted version of it appears in Reynolds’ origi¬ 
nal paper on the polymorphic lambda calculus [Rey74], 
where it is called the representation theorem, and a 
version similar to that used here appears in [Rey83], 
where it is called the abstraction theorem. Other 
versions include the logical relations of Mitchell and 
Meyer [MM85, Mit86]; and the dinatural transforma¬ 
tions of Bainbridge, Freyd, Girard, Scedrov, and Scott 
[BFSS87, FGSS88], from whom I have taken the name 
“parametricity”. 

So far as I am aware, all uses of parametricity to date 
have been “general” : they say something about possible 
implementations of the polymorphic lambda calculus 
(e.g. that the implementation is correct independent of 
the representation used) or about its models (e.g. that 
models should only be allowed that satisfy parametric¬ 
ity). The main contribution of this paper is to suggest 
that parametricity also has “specific” applications: it 
says interesting things about particular functions with 
particular types 2 3 . 

An updated statement and proof of the abstraction 
theorem is presented. The main reason for including 
these is to make the paper self-contained. In the pro¬ 
cess, it is easy to repair a minor lacunae in Reynold’s 
original presentation [Rey83]. That version is expressed 
in terms of a “naive” set-theoretic model of the polymor¬ 
phic lambda calculus; Reynolds later proved that such 
models do not exist [Rey84]. There is nothing wrong 
with the theorem or the proof itself, just the context 
in which it is set, and it is straightforward to transpose 
it to another context. This paper uses the frame mod¬ 
els of Bruce, Meyer, and Mitchell [BM84, MM85]. For 
other models of the polymorphic lambda calculus, see 
[BTC88, Mes89, Pit87]. 

The characterisation of parametricity given in this pa¬ 
per can be formulated more concisely in terms of cat¬ 
egory theory, where it can be re-expressed in terms of 
lax natural transformations. This will be the subject of 
a further paper. 

The remainder of this paper is organised as follows. 
Sections 2 and 3 present the main new results: Section 2 

2 This is similar to the restriction to strict coercion functions 
in [BCGS89], and is adopted for a similar reason. 

3 Since this paper was written, I have learned that Peter de- 
Bruin has recently discovered similar applications [deB89], and 
that John Reynolds already knew of the application in Section 3.8. 


presents the parametricity theorem, and Section 3 gives 
further applications. Sections 4-6 fill in the formali¬ 
ties: Section 4 describes the syntax of the polymor¬ 
phic lambda calculus, Section 5 shows how its syntax 
can be given using frame models, and Section 6 gives 
the full statement of the parametricity theorem. Sec¬ 
tion 7 shows how the parametricity theorem should be 
adjusted to account for languages that use the hxpoint 
operator. 

Acknowledgements. I am grateful to Harold Sim¬ 
mons for helping to formulate and prove the result 
about map in Section 3.5, and to Samson Abramsky, 
Val Breazu-Tannen, Peter Freyd, John Hughes, John 
Launchbury, John Reynolds, Andre Scedrov, and Mary 
Sheeran for their comments on this work. 


2 Parametricity explained 

The key to extracting theorems from types is to read 
types as relations. This section outlines the essential 
ideas, using a naive model of the polymorphic lambda 
calculus: types are sets, functions are set-theoretic func¬ 
tions, etc. The approach follows that in [Rey83]. 

Cognoscenti will recognise a small problem here— 
there are no naive set-theoretic models of polymorphic 
lambda calculus! (See [Rey84].) That’s ok; the essen¬ 
tial ideas adopt easily to frame models [BM84, MM85]. 
This section sticks to the simple but naive view; the i’s 
will be dotted and the t’s crossed in Sections 4-6, which 
explain the same notions in the context of frame models. 

The usual way to read a type is as a set. The type 
Bool corresponds to the set of booleans, and the type 
Int corresponds to the set of integers. If A and B are 
types, then the type Ax B corresponds to a set of pairs 
drawn from A and B (the cartesian product), the type 
A* corresponds to the set of lists with elements in A, and 
the type A —>■ B corresponds to a set of functions from A 
to B. Further, if A is a type variable and A(X) is a type 
depending on X, then the type VA. A{ A) corresponds 
to a set of functions that take a set B and return an 
element in A(B). 

An alternative is to read a type as a relation. If A 
and A' are sets, we write A : A O A' to indicate that 
A is a relation between A and A', that is, that A C 
A x A'. If x £ A and x' £ A', we write ( x,x') £ A 
to indicate that x and x' are related by A. A special 
case of a relation is the identity relation I a : A O A, 
defined by I a = {{x,x) \ x £ A}. In other words, if 
x,x' £ A, then (x,x') £ I a iff x = x'. More generally, 
any function a : A —> A' may also be read as a relation 
{(a:, ax) \ x £ A}. In other words, if x £ A and x' £ A ', 
then (x, x') £ a iff a x = x'. 
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To read types as relations, we give a relational equiva¬ 
lent for constant types and for each of the type construc¬ 
tors Ax B, A *, A —>■ B, and MX. A(X). Constant types, 
such as Bool and Int, may simply be read as identity 
relations, IbooI ■ Bool O Bool and Ij nt : Int O Int. 

For any relations A : A O A' and B : B O B ', the 
relation A x B : (A x B) O (A' x B') is defined by 

((x,y),(x',y'))eAxB 

iff 

(x, x') E A and ( y , y') E B. 

That is, pairs are related if their corresponding com¬ 
ponents are related. In the special case where a and 
b are function, then a x b is the function defined by 
(ax 6) (x,y) = (a x,by). 

For any relation A : A O A', the relation A* : A* O 
A'* is defined by 

{[xi , • • •, x n \, [x), . . ., x' n ]) E A* 

iff 

(xijXj) E a and . . . and (x n , x' n ) E A. 

That is, lists are related if they have the same length 
and corresponding elements are related. In the special 
case where a is a function, a* is the familiar “map” 
function defined by a* [xj , . . ., x n ] = [a x± , . . ., a x n \. 

For any relations A : A O A' and B : B O B ', the 
relation .4 —S- F> : (A —» .B) O (A' —>■ B') is defined by 

(fJ')eA^B 

iff 

for all (x, x') E A, (fx,f'x')eB. 

That is, functions are related if they take related argu¬ 
ments into related results. In the special case where a 
and b are functions, the relation a —>■ b will not neces¬ 
sarily be a function, but in this case (/, f) E a —> b is 
equivalent to /' o a = b o f. 

Finally, we have to interpret V as an operation on re¬ 
lations. Let F{X) be a relation depending on X. Then 
T corresponds to a function from relations to relations, 
such that for every relation A : A O A' there is a cor¬ 
responding relation F{A) : F(A) O F'(A'). Then the 
relation MX. T{X) : MX. F(X) O MX'. F'(X') is defined 
by 

(g,g')eMX.F(X) 

iff 

for all .4 : A O 4', {g A ,g' A ,) G F{A). 

That is, polymorphic functions are related if they take 
related types into related results. (Note the similarities 
in the definitions of A —> B and MX. F(X).) 

Using the definitions above, any closed type T (one 
containing no free variables) can be read as a relation 
T : T O T. The main result of this paper can now be 
described as follows: 


Proposition. (Parametricity.) If t is a 
closed term of type T, then (t, t) E T, where 
T is the relation corresponding to the type T. 

A more formal statement of this result appears in Sec¬ 
tion 6, where it is extended to types and terms contain¬ 
ing free variables. 

3 Parametricity applied 

This section first explains in detail how parametricity 
implies some of the theorems listed in the introduction 
and then presents some more general results. 

3.1 Rearrangements 

The result in the introduction is a simple consequence 
of parametricity. Let r be a closed term of type 

r : MX. X* ->■ A*. 

Parametricity ensures that 

(r, r) E MX. X* —»■ X*. 

By the definition of V on relations, this is equivalent to 

for all A : A O A ', 

(r A ,r A ,) eA* A* 

By the definition of —y on relations, this in turn is equiv¬ 
alent to 

for all A : A O A ', 
for all (xs, xs') E A*, 

(r A xs, r A , xs') E A* 

This can be further expanded in terms of the definition 
of A*. A more convenient version can be derived by 
specialising to the case where the relation A is a function 
a : A —» A'. The above then becomes 

for all a : A —>■ A ', 
for all xs, 

a* xs = xs' implies a* (r A xs) = r A > xs' 
or, equivalently, 

for all a : A —> A ', 


This is the version given in the introduction. 

3.2 Fold 

The function fold has the type 

fold : MX. MY. {X Y Y) Y X* Y. 









Parametricity implies that 

(fold, fold) e vt. vy (x y y) -+ y -+ x* -+ y. 

Let a : A —> A' and b : B —> B' be two functions. Ap¬ 
plying the definition of V on relations, twice, specialised 
to functions, gives 

(fold AB ,fold A . B 0 G (afc) -> 6-> a* -t t 

Applying the definition of —> on relations, twice, gives 

for all (©, ©') E (a —> b —> b), 
for all («, «') E b, 

(fold AB (©) u,fold A i B i (©') «') E a* ->■ b. 

Here (©) is just the name of a function of two argu¬ 
ments; by the usual convention, (©) x y may be written 
in the infix form x ® y. Further expansion shows that 
the condition (©, ©') E (a —> b —> b) is equivalent to 

for all x E A, x' E A', y E B, y' E B', 

a x = x' and b y = y' implies b (x ® y) = x' ©' y'. 

The result as a whole may then be rephrased, 

for all a : A -> A', b : B -+ B', 

if for all x E A, y E B, b (x © y) = (a x) ©' (b y), 
and b u = «' 

then b o fold AB (©) « = fold A < B ' (©') u' o a*. 

The theorems derived from types can often be given a 
reading with an algebraic flavour, and the result about 
fold provides an illustration of this. Let (A,B,®,u) 
and (A', B', ©', «') be two algebraic structures. The 
functions a and b form a homomorphism between 
these if b (x © y) = (a x) ©' (b y) for all x and y, 
and if b u = Similarly, let (A*, B, fold AB (©) «) 
and (A'*, B' ,fold A i B i (©') «') also be two algebraic 
structures. The functions a* and b form a homo¬ 
morphism between these if b ( fold AB (©) « xs) = 
fold A i B i (©') u' (a* xs). The result about fold 
states that if a and b form a homomorphism between 
(A,B,c,n) and (A 1 , B', c', n'), then a* and b form 
a homomorphism between ( A*,B,fold AB (©) «) and 
( A 1 *, B 1 ,fold A i B i (©') «')• 

3.3 Sorting 

Let s be a closed term of the type 

s : VX.(X —t A —t Bool ) ^ (X* -+ X*) 

Functions of this type include sort and nub: 

sort Int (< Int )[3,l,4,2,5] = [1,2, 3,4,5] 

nub Int (= Int )[l,l,2,2,2,l] = [1,2,1] 


The function sort takes an ordering function and a list 
and returns the list sorted in ascending order, and the 
function nub takes an equality predicate and a list and 
returns the list with adjacent duplicates removed. 

Applying parametricity to the type of s yields, for all 
a : A -> A', 

if for all x, y E A, (x © y) = (a x ©' a y) then 
a* o Sj4 (®) = s j4 -(®') o a* 

(Recall that Bool as a relation is just the identity rela¬ 
tion of booleans.) As a corollary, we have 

if for all x, y E A, (x < y) = (a x <’ a y) then 
sort AI (<) o a* = a* o sort A (<') 

so maps commute with sort, when the function mapped 
preserves ordering. (If < and <' are linear orderings, 
then the hypothesis is equivalent to requiring that a is 
monotonic.) As a second corollary, we have 

if for all x, y E A, (x = y) = (a x =' a y) then 
nub A i (=) o a* = a* o nub A (=') 

so maps commute with nub, when the function mapped 
preserves equivalence. (If = and =' are equality on A 
and A 1 , then the hypothesis is equivalent to requiring 
that a is one-to-one.) 

3.4 Polymorphic equality 

The programming language Miranda [Tur85] provides a 
polymorphic equality function, with type 

(=) : MX. A —» A —>■ Bool. 

Applying parametricity to the type of (=) yields, for all 
a : A -> A 1 , 

for all x, y E A, (x = A y) = (a x = A i a y). 

This is obviously false; it does not hold for all a, but 
only for functions a that are one-to-one. 

This is not a contradiction to the parametricity theo¬ 
rem; rather, it provides a proof that polymorphic equal¬ 
ity cannot be defined in the pure polymorphic lambda 
calculus. Polymorphic equality can be added as a con¬ 
stant, but then parametricity will not hold (for terms 
containing the constant). 

This suggests that we need some way to tame the 
power of the polymorphic equality operator. Exactly 
such taming is provided by the eqtype variables of Stan¬ 
dard ML [Mil87], or more generally by the type classes 
of Haskell [HW88, WB89]. In these languages, we can 
think of polymorphic equality as having the type 

(=) :V (=) A. A —» A —» Bool. 
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Here \A = ) A. F(X) is a new type former, where X ranges 
only over types for which equality is defined. Corre¬ 
sponding to the type constructor is a new relation 
constructor: 

(9,J')6V(=^. T(X) 

iff 

for all A : A O A! respecting (=), (g A , g' A ,) E F(A). 

A relation A : A O A' respects (=) if A relates equals 
to equals; that is, if whenever x = A y and {x,x') E A 
and (y,y r ) & A then x' = A i y', where (=a) is equality 
on A and (=a') is equality on A'. In the case where A 
is a function a, this is equivalent to requiring that a be 
one-to-one. 

With this definition, we can prove that the polymor¬ 
phic equality operator, typed as above, satisfies the 
parametricity theorem. In our extended language we 
can define, for example, the function 

nub :V(=iA. A* —>■ A* 

and the corresponding parametricity condition is the 
same as that for the previous version of nub. 

Thus, the more refined type structures of Standard 
ML and Haskell add exactly the information necessary 
to maintain parametricity. In Standard ML this trick 
works only for equality (which is built into the lan¬ 
guage), whereas in Haskell it works for any operators 
defined using the type class mechanism. 

3.5 A result about map 

Suppose that I tell you that I am thinking of a function 
m with the type 

m : VA.VY.(A -► Y) -+ (A* -► Y*) 

You will immediately guess that I am thinking of the 
map function, m(f) = f*. Of course, I could be thinking 
of a different function, for instance, one that reverses a 
list and then applies f* to it. But intuitively, you know 
that map is the only interesting function of this type: 
that all others must be rearranging functions composed 
with map. 

We can formalise this intuition as follows. Let m be 
a function with the type above. Then 

m AB (f) = f*° m AA (I A ) = m B B (Ib) ° f* 

where I A is the identity function on A. The function 
m AA (I A ) is a rearranging function, as discussed in the 
preceding section. Thus, every function m of the above 
type can be expressed as a rearranging function com¬ 
posed with map, or equivalently, as map composed with 
a rearranging function. 


The proof is simple. As we have already seen, the 
parametricity condition for m is that 

if /' o a = b o / then m A - B - (/') o a* = b* o m AB (/) 

Taking A' = B' = B, b = /' = I B , a = / satisfies the 
hypotheses, giving as the conclusion 

m BB (I B ) of* = (Ib)* ° m AB (f) 

which gives us the second equality above, since (Ib)* = 
I B >. The first equality may be derived by commuting 
the permuting function with map; or may be derived 
directly by a different substitution. 

3.6 A result about fold 

Analogous to the previous result about map is a similar 
result about fold. Let / be a function with the type 

/ : VA.V Y.(A Y —» Y) —» Y —>■ X* —>■ Y 

Then 

f AB c n = fold AB c n o f AA , cons A ml A 

Note that f AA - cons A ml A : A* —> A* is a function that 
rearranges a list, so this says that every function with 
the type of fold can be expressed as fold composed with 
a rearranging function. 

The proof is similar to the previous one. The para¬ 
metricity condition for / is that 

if c' o (a x 6) = b o c and n' = b(n) then 
f A 'B' c' n' o a* = b o f AB c n 

Taking A = A 1 , B = A*, a = I A , b = fold A > B > d n', 
c = consj i, n = ml A satisfies the hypothesis, giving as 
the conclusion 

f AB > o' n' o I* A = fold AB i cJ n' o f AA , cons A ml A 

The I A term is just an identity, and so drops out, leaving 
us with the desired equality if we rename c', n',B' to 
c, n,B. 

3.7 A result about filter 

Let / be a function with the type 

/ : VA.(A ->■ Bool) ->■ A* ->■ A* 

Three functions with this type are filter, takewhile, and 
dropwhile. For example, 

filter odd [3, 1,4,5,2] = [3,1,5] 

takewhile odd [3, 1,4,5, 2] = [3,1] 
dropwhile odd [3, 1,4,5, 2] = [4,5,2] 




See [BW88] for the definitions of these functions. 

For every such / we can define a corresponding func¬ 
tion of type 

g :MX.(X x Bool)* -A X* 
such that / and g are related by the equation 

Ia(p) = gA ° (Ia,p) (*) 

where ( I A ,p)x = (x,px). That is, f A is passed a pred¬ 
icate p of type A —> Bool and a list of A, whereas gA is 
passed a list of A x Bool pairs, the second component 
of the pair being the result of applying p to the first 
component. Intuitively, this transformation is possible 
because the only values that p can be applied to are of 
type A, so it suffices to pair each value of type A with 
the result of applying p to it. 

A little thought shows that a suitable definition of g 

fit4 = fst* o f A xBooi(snd) 

We can use parametricity to show that / and g sat¬ 
isfy (*), for all functions / of the given type. The 
parametricity conditions for / tells us that for any 
a : A —> A' and any p : A -A- Bool and p' \ A' Bool 
we have 

if P' o a = IbooI o P then f A >(p') ° a* = a* o f A (p) 

Take A' = A x Bool and a = (Ia,p) and p' = snd. 
Then the hypothesis becomes snd o (Ia,p) = P, which 
is satisfied, yielding the conclusion 

fAxBooi(snd) o (I A ,p)* = {I A ,p)* of A (p). 

Compose both sides with fst* , giving 

fst* °f A xBooi(snd) o (I A ,p)* = fst* o (I A ,p)* of A (p). 

Then apply the definition of g, and observe that fst o 
{IA , p) = I a, resulting in the equation 

9a o (Ia,p)* — f a( p ) 

as desired. 

3.8 An isomorphism 

The preceding applications can all be expressed in the 
Hindley/Milner fragment of the polymorphic lambda 
calculus: all universal quantifiers appear at the outside 
of a type. This section presents an application that 
utilises the full power of the Girard/Reynolds system. 

Let A be an arbitrary type. Intuitively, this type 
is isomorphic to the type MX. (A —» A) —» A, which 


we will abbreviate as A. The apparent isomorphism 
between A and A is expressed by the functions: 

i : A -A A 

i = A x : A AX. \g : A -A X. g x 
] : A -A A 

j = A h : A h A {Xx : A x) 

That is, i takes an element a: of A to the element of A 
that maps a function g (of type A —y X) to the value 
g x (of type X). The inverse function j recovers the 
original element by applying a value in A to the identity 
function. 

To prove that this truly is an isomorphism, we must 
verify that j o i and i o j are both identities. It is easy 
enough to verify the former: 

j (i x) 

= ] (AX. \g : A ^ X. g x) 

= (Xg : A -A A g x) (Xx : A x) 

= (Xx : A x) x 
= x 

However, the inverse identity is problematic. We can 
get as far as 

* O' h) 

= i (h A (Xx : A z)) 

= AX.Xg-.A^X.g (h A (Xx : A x)) 

and now we are stuck. Here is where parametricity 
helps. The parametricity condition for h : MX. (A —> 
X) — ► X is that, for all b : B —y B' and all / : A —y B y 

b(h B f) = h B - (bof ) 

Taking B = A, B 1 = X, b = g, and / = (Xx : A x) 
gives 

AX. Xg : . 1 • A. g (h A (Xx : A z)) 

= AX. Xg : A ^ X. h x (g o (Xx : A z)) 

= AX.Xg-.A^ X. h x g 
= h 

which completes the second identity. 

The second identity depends critically on parametric¬ 
ity, so the isomorphism holds only for models in which 
all elements satisfy the parametricity constraint. Alas, 
the parametricity theorem guarantees only that ele¬ 
ments of the model that correspond to lambda terms 
will be parametric; many models contain additional el¬ 
ements that are non-parametric. One model that con¬ 
tains only parametric elements is that in [BTC88]. 
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A —>■ B must be in U, and if F is in [U —► U], then MF 
must be in U. 

Let T be a type with its free variables in X. We say 
that A is a type environment for X if it maps each type 
variable in X into a type value in U. The corresponding 
value of T in the environment A is written [T]A and is 
defined as follows: 


IXJA 

= A{XJ 

\T -A- UjA 

= [T]A —» \_U\A 

[VA. TJA 

= V(A A[T\A[A/X]) 


Here A[A] is the value that A maps X into, and A[A/X] 
is the environment that maps X into A and otherwise 
behaves as A. (The reader may find that the above 
looks more familiar if A is replaced everywhere by a 
Greek letter such as rj.) 

5.2 Terms 

Associated with each type A in U is a set D a of the 
values of that type. 

For each A and B in U, the elements in D aa-b repre¬ 
sent functions from D a to D5. We do not require that 
the elements are functions, merely that they represent 
functions. In particular, associated with each A and B 
in U there must be a set [D^ -tDg] of functions from 
D a to D b, and functions 

<t>A,B : D A ab -t [D^ -q Dg] 

^A,B ■ [Da -t D s ] -q D A ab 

such that 4>a,b 0 ipA,B is the identity on [D^ q Dg], 
We will usually omit the subscripts and just write <f> and 

If F is a function in [U — y U], the elements in Dyg 
represent functions that take a type A into an element 
of In particular, associated with each F there 

must be a set [VA : U. of functions that map 

each A in U into an element of and functions 

<Pf : Dyjr -q [VA : U. D F(jt) ] 

W F : [VA : U. D F(jt) ] -q D VF 

such that <P F o F f is the identity on [VA : U. Dg^j], 
Again, we will usually omit the subscripts and just write 
<P and W. 

Let t be a term such that X; x b t : T. We say that 
A, a are environments respecting X,x if A is a type 
environment for X and a is an environment mapping 
variables to values such that for each x t : T % in x, we 
have that a[x t J £ D[ Tj jq. The value of t in the envi¬ 
ronments A and a is written [t]Aa and is defined as 
follows: 


IxjAd 

= 

[A* : U. v}Ad 

= if {\a.lvlAd[a/x]) 

\t «] A a 

= <t> (PP«) ([«P«) 

{AX.yjA d 

= V (AA MA[A/X] d) 

\tu\A a 

= $ (iqAd) (iu}A) 


Here a [a;] is the value that a maps x into, and a[a/x\ 
is the environment that maps x into a and otherwise 

A frame is a structure specifying U,—y, V and 
D, <f>, ip, <P, W satisfying the constraints above. A frame 
is an environment model if for every X ; x b t : T and 
every A, a respecting X,x, the meaning of [t]Ad as 
given above exists. (That is, a frame is a model if the 
sets [U -q U], [[D a -q D s ], and [VA : U. D f(jl) ] are 
“big enough”.) 

We write X ; x \= t : T if for all environments A, a 
respecting X,x, we have [t]Ad £ D[ T jq. 

Proposition. (Soundness of types.) For all 

X, x, t and T, if X;x b t : T then X;x\=t: 

T. 

The type soundness result simply states that the mean¬ 
ing of a typed term corresponds to the meaning of the 
corresponding type. The proof is a straightforward in¬ 
duction over the structure of type inferences. Para- 
metricity is an analogue of this result, as we shall see in 
the next section. 

6 The parametricity theorem 

In the previous section, we defined a semantics where 
a type environment A consists of a mapping of type 
variables onto types, and the semantics of a type T 
in the environment A is a set denoted D[ T p. In this 
section, we define an alternative semantics where a type 
environment A consists of a mapping of type variables 
onto relations, and the semantics of a type T in the 
environment A is a relation denoted [T]A. 

We can then formally state the parametricity theo¬ 
rem: terms in related environments have related val¬ 
ues. We can think of environments A and A' as specify¬ 
ing two different representations of types, related by A, 
which is why Reynolds’ called his version of this result 
“the abstraction theorem”. A key point of this paper 
is that this theorem has applications other than change 
of representation, hence the change in name from “ab¬ 
straction” to “parametricity” 

A function type may be regarded as a relation as fol¬ 
lows. If A : A O A' and B B B' are two relations, 
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then we define 

A^B: {A^ B) o (A' -Y B') 

to be the relation 

A^B={ (/,/') | (a, a 1 ) E A implies 
{4>faAf a')EB} 

In other words, functions are related if they map related 
arguments into related results. 

A type abstraction may be regarded as a relation as 
follows. Let F be a function from U to U, and F' be a 
function from U' to U', and for each A in U and A' in 
U', let Jbea function that takes a relation A : A O A' 
and returns a relation T(A) : F(A) O F'(A'). Then we 
define 

iT : iF o iF' 

to be the relation 

'iT = { (g, g’) | for all A, A', and A : A O A', 
(Mg)(A), $W) (A')) eT(A) } 

In other words, type abstractions are related if they map 
related types into related results. 

A relation environment maps each type variable into 
a relation. Let A be a relation environment for X , and 
let A, A' be two type environments for X. We write 
A : A O A' if for each A in A we have A[ A] : A[ A] O 
A'[A], 

Given a relation environment A we can interpret a 
type T as a relation [TJ.4 as follows: 



= -4[A] 

\u —t v}A 

= lujA^lvjA 

[VA. V\A 

= V(AA IV}A[A/ A]) 


Let A, a respect X,x and A' , a' respect X,x. We 
say that A,A,A', a, a' respect A, x if A : A O A' and 
(»W, G [T,]Afor each x t : T % in x. It is easy to 

see that if A, A, A' , a, a' respect A, x then A, a respect 
A, x and A', a' respect A, x. 

We say that A; x ||= t : T iff for every A, A, A', a, a' 
that respect X,x we have (|f]Aa, [fJA'a') £ [T]A 

Proposition. (Parametricity.) For all A, 
x, t, and T, ifX-x \~ t : T then A; x ||= t : T. 

Proof. The proof is a straightforward induction over 
the structure of type inferences. For each of the infer¬ 
ence rules in Figure 2, we replace b by ||= and show that 
the resulting inference is valid. (End of proof.) 


As mentioned previously, data types such as booleans, 
pairs, lists, and natural numbers can be defined in terms 
of —y and V. 

As an example, consider the construction for pairs. 
The type A x Y is defined as an abbreviation: 

Ax Y d = iZ. (X Y Z) Z 

Every term of type A x Y is equivalent to a term of the 
form pairxY x y, where x : A and y : Y , and pair is 
defined by 

paw d = AX. AY. Ax : X. Ay : Y. 

AZ. Ap : X —» Y —» Z. p x y 

The type of pair is, of course, 

paw : VA. VY.AqfqAx Y 

where A x Y stands for the abbreviation above. It 
follows from the parametricity theorem that ifA'.A^- 
A' and B : B -> B' , and (a, a') E A and (6, 6') £ B, 
then 

( {pairxY x yJ[A/X,B/Y] [a/x, b/y], 

1PairxY x y] [A 1 /X, B 1 / Y] [a'/x,b'/y\ ) 

G [A x YJ[A/X,B/Y}. 

That is, pairs are related if their corresponding compo¬ 
nents are related, as we would expect. 

It can be shown similarly, using the standard con¬ 
struction for lists, that lists are related if they have the 
same length and corresponding elements are related. 

Alternatively, suitable type constructors and individ¬ 
ual constants may be added to the pure polymorphic 
lambda calculus. In this case, for each new type con¬ 
structor an appropriate corresponding relation must be 
defined; suitable definitions of relations for pair and list 
types were given in Section 2. Further, for each new 
constant the parametricity condition must be verified: 
if c is a constant of type T , we must check that ||= c : T 
holds. It then follows that parametricity holds for any 
terms built from the new type constructors and con¬ 
stants. 

7 Fixpoints 

Every term in typed lambda calculus is strongly nor¬ 
malising, so if a hxpoint operator is desired it must be 
added as a primitive. This section mentions the addi¬ 
tional requirements necessary to ensure that the hxpoint 
primitive satisfies the abstraction theorem. 

Frame models associate with each type A a set D^. 
In order to discuss fixpoints, we require that each set 
have sufficient additional structure to be a domain: it 
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must be provided with an ordering C such that each 
domain has a least element, _L, and such that limits of 
directed sets exist. Obviously, we also require that all 
functions are continuous. 

What are the requirements on relations? The obvious 
requirement is that they, too, be continuous. That is, 
if A : A O A', and x t is a chain in A, and x( is a 
chain in A', and (x t , x'f) E A for every i, then we require 
that dJarLK) E A also. But in addition to this, we 
need a second requirement, namely that each relation 
A is strict, that is, that (_La,-La') £ A. If we restrict 
relations in this way, then it is no longer true that every 
function a : A ^ A' may be treated as a relation; only 
strict functions may be treated as such. 

With this restricted view of relations, it is easy to 
show that the hxpoint operator satisfies the parametric- 
ity theorem. As usual, for each type A define fix a as the 
function 

fix : MX. (X^X)^X 

such that fixA f = |_|/ ! La- Parametricity holds if 
(fix, fix) E MA (A A) A. This will be true if 
for each A : A O A' and each (/,/') E A —> A we 
have (fix a f ,fixA' f) £ A. Recall that the condition on 
/ and /' means that if (x,x') E A then (/ x,f x') E 
A. Now, since all relations are strict, it follows that 
(-La, J -a‘) £ A; hence (/ _L A ,f J -a 1 ) £ A; and, in gen¬ 
eral, (/* 1 A,f l J -A') £ A. It follows, since all relations 
are continuous, that ([J/* J-a,|J/ ,! T a 1 ) £ A, as re¬ 
quired. 

Note that the restriction to strict relations here is 
similar to the restriction to strict coercion functions in 
[BCGS89], and is adopted for similar reasons. 

The requirement that relations are strict is essen¬ 
tial. For a counterexample, take A to be the domain 
{_L, true, false], and take A : A —> A to be the constant 
relation such that (x, true ) E A for all x. The relation 
A is continuous but not strict. Let / be the constant 
function f x = false and let /' be the identity function 
/' x = x. Then A —> A relates / to /', but A does not 
relate fix a f = false to fix a f = -L. 

The restriction to strict arrows is not to be taken 
lightly. For instance, given a function r of type 

r : MA.A* ->■ A* 
parametricity implies that 


for all functions a : A —> A'. If the hxpoint combinator 
appears in the definition of r, then we can only conclude 
that the above holds for strict a, which is a significant 
restriction. 


The desire to derive theorems from types therefore 
suggests that it would be valuable to explore program¬ 
ming languages that prohibit recursion, or allow only 
its restricted use. In theory, this is well understood; we 
have already noted that any computable function that is 
provably total in second-order Peano arithmetic can be 
defined in the pure polymorphic lambda calculus, with¬ 
out using the hxpoint as a primitive. However, practical 
languages based on this notion remain terra incognita. 
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